Cross-Origin-Embedder-Policy (COEP) header
Der HTTP Cross-Origin-Embedder-Policy
(COEP) Antwort-Header konfiguriert die Richtlinie des aktuellen Dokuments für das Laden und Einbetten von Cross-Origin-Ressourcen.
Die Richtlinie dafür, ob eine bestimmte Ressource seitenübergreifend eingebettet werden kann, kann für diese Ressource mit dem Cross-Origin-Resource-Policy
(CORP)-Header für einen no-cors
-Abruf oder mit CORS definiert werden.
Wenn keine dieser Richtlinien festgelegt ist, können Ressourcen standardmäßig in ein Dokument geladen oder eingebettet werden, als hätten sie einen CORP-Wert von cross-site
.
Die Cross-Origin-Embedder-Policy
erlaubt es Ihnen, zu verlangen, dass CORP- oder CORS-Header gesetzt sind, um seitenübergreifende Ressourcen in das aktuelle Dokument zu laden.
Sie können die Richtlinie auch so einstellen, dass das Standardverhalten beibehalten wird oder dass das Laden der Ressourcen erlaubt ist, aber jegliche Anmeldeinformationen, die sonst gesendet würden, entfernt werden.
Die Richtlinie gilt für geladene Ressourcen sowie für Ressourcen in <iframe>
s und verschachtelten Frames.
Hinweis:
Die Cross-Origin-Embedder-Policy
überschreibt oder beeinflusst nicht das Einbetten einer Ressource, für die CORP oder CORS eingestellt wurde.
Wenn CORP eine Ressource darauf beschränkt, dass sie nur same-origin
eingebettet werden darf, wird sie unabhängig vom COEP-Wert nicht seitenübergreifend in eine Ressource geladen.
Header-Typ | Antwort-Header |
---|---|
Verbotener Name des Antwort-Headers | Nein |
Syntax
Cross-Origin-Embedder-Policy: unsafe-none | require-corp | credentialless
Direktiven
unsafe-none
-
Erlaubt es dem Dokument, Cross-Origin-Ressourcen ohne explizite Erlaubnis durch das CORS-Protokoll oder den
Cross-Origin-Resource-Policy
-Header zu laden. Dies ist der Standardwert. require-corp
-
Ein Dokument kann nur Ressourcen von derselben Herkunft laden oder Ressourcen, die ausdrücklich als von einer anderen Herkunft ladbar deklariert sind.
Das Laden von Cross-Origin-Ressourcen wird von COEP blockiert, es sei denn:
- Die Ressource wird im
no-cors
-Modus angefordert und die Antwort enthält einenCross-Origin-Resource-Policy
-Header, der es erlaubt, sie in die Dokumentherkunft zu laden. - Die Ressource wird im
cors
-Modus angefordert und die Ressource wird von CORS unterstützt und erlaubt. Dies kann beispielsweise in HTML durch die Verwendung descrossorigin
-Attributes geschehen oder in JavaScript durch eine Anfrage mit{mode="cors"}
.
- Die Ressource wird im
credentialless
-
Ein Dokument kann Cross-Origin-Ressourcen laden, die im
no-cors
-Modus ohne eine ausdrückliche Erlaubnis über denCross-Origin-Resource-Policy
-Header angefordert werden. In diesem Fall werden Anfragen ohne Anmeldeinformationen gesendet: Cookies werden in der Anfrage weggelassen und in der Antwort ignoriert.Das seitenübergreifende Ladeverhalten für andere Anforderungsmodi ist dasselbe wie für
require-corp
. Zum Beispiel muss eine imcors
-Modus angeforderte Cross-Origin-Ressource CORS unterstützen (und durch CORS erlaubt sein).
Beispiele
Funktionen, die von der Isolation über Parteien hinweg abhängen
Bestimmte Funktionen, wie der Zugriff auf SharedArrayBuffer
-Objekte oder die Verwendung von Performance.now()
mit ungedrosselten Timern, sind nur verfügbar, wenn Ihr Dokument cross-origin isoliert ist.
Um diese Funktionen in einem Dokument zu verwenden, müssen Sie den COEP-Header mit dem Wert require-corp
oder credentialless
setzen und den Cross-Origin-Opener-Policy
-Header auf same-origin
.
Zusätzlich darf die Funktion nicht durch Permissions-Policy: cross-origin-isolated
blockiert sein.
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Sie können die Eigenschaften Window.crossOriginIsolated
und WorkerGlobalScope.crossOriginIsolated
verwenden, um zu prüfen, ob die Funktionen in Fenster- und Worker-Kontexten eingeschränkt sind:
const myWorker = new Worker("worker.js");
if (crossOriginIsolated) {
const buffer = new SharedArrayBuffer(16);
myWorker.postMessage(buffer);
} else {
const buffer = new ArrayBuffer(16);
myWorker.postMessage(buffer);
}
Vermeidung von COEP-Blockierung mit CORS
Wenn Sie COEP mit require-corp
aktivieren und eine Cross-Origin-Ressource einbetten möchten, die CORS unterstützt, müssen Sie explizit angeben, dass sie im cors
-Modus angefordert wird.
Um beispielsweise ein in HTML deklariertes Bild von einer Drittanbieter-Website abzurufen, die CORS unterstützt, können Sie das crossorigin
-Attribut verwenden, damit es im cors
-Modus angefordert wird:
<img src="https://thirdparty.com/img.png" crossorigin />
Sie können das HTMLScriptElement.crossOrigin
-Attribut oder das Abrufen mit { mode: 'cors' }
ähnlich verwenden, um eine Datei im CORS-Modus mittels JavaScript anzufordern.
Wenn für einige Bilder CORS nicht unterstützt wird, kann ein COEP-Wert von credentialless
als Alternative verwendet werden, um das Bild ohne explizite Zustimmung des Cross-Origin-Servers zu laden, allerdings auf Kosten der Anforderung ohne Cookies.
Spezifikationen
Specification |
---|
HTML # coep |
Browser-Kompatibilität
Siehe auch
Cross-Origin-Opener-Policy
Window.crossOriginIsolated
undWorkerGlobalScope.crossOriginIsolated
- Cross Origin Opener Policy in Why you need "cross-origin isolated" for powerful features auf web.dev (2020)
- COOP and COEP explained: Artur Janc, Charlie Reis, Anne van Kesteren (2020)